맨위로가기

고속 응용 프로그램 개발

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

고속 응용 프로그램 개발(RAD)은 1970~80년대의 전통적인 소프트웨어 개발 방식에 대한 대안으로 등장했다. RAD는 프로토타입 개발을 강조하며 위험 감소, 사용자 피드백 용이성 등의 이점을 제공한다. 제임스 마틴은 RAD 접근 방식을 개발하고, 1991년 관련 서적을 출판하여 이를 공식화했다. 대한민국에서는 1990년대 후반 RAD 도구의 도입과 함께 웹 애플리케이션 개발 수요 증가로 널리 사용되었으며, 최근에는 애자일 방법론과 함께 유연한 애플리케이션 개발에 활용된다. 제임스 마틴의 RAD 접근 방식은 요구 사항 계획, 사용자 설계, 구축, 전환의 4단계로 이루어진다. RAD는 개발 생산성 향상, 위험 관리, 프로젝트 완료 가능성 증가 등의 장점이 있지만, 초기 적응의 어려움, 비기능 요구 사항에 대한 고려 부족, 사용자 참여의 필요성, 대규모 프로젝트에 대한 적용의 어려움 등의 단점도 존재한다.

더 읽어볼만한 페이지

  • 고속 개발 도구 - 크로스 플랫폼
    크로스 플랫폼은 소프트웨어나 애플리케이션이 다양한 운영 체제, 하드웨어 플랫폼 또는 이들의 조합에서 동작할 수 있도록 하는 기술을 의미하며, 웹 애플리케이션 형태로 구현되거나 플랫폼 연동을 통해 하드웨어 경계를 넘어 콘텐츠를 즐길 수 있도록 한다.
  • 고속 개발 도구 - LabVIEW
    LabVIEW는 내쇼날 인스트루먼트에서 개발한 그래픽 기반 프로그래밍 환경으로, 시각적인 블록 다이어그램을 사용하여 데이터 수집, 계측기 제어, 자동화 시스템 구축 등에 활용되며 사용자 인터페이스 생성 통합, 병렬 프로그래밍 지원, 다양한 디자인 패턴 제공을 통해 복잡한 애플리케이션 개발을 돕는다.
  • 소프트웨어 프로젝트 관리 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 개발 - 유스 케이스
    유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
  • 소프트웨어 개발 - 사용자 경험 디자인
    사용자 경험 디자인은 인간 공학에 기반하여 제품 또는 서비스와 사용자 간의 상호작용을 설계하는 분야이며, 사용자 조사, 인터랙션 디자인, 사용성 테스트 등을 통해 효율적이고 만족스러운 경험을 제공하는 것을 목표로 한다.
고속 응용 프로그램 개발
고속 응용 프로그램 개발
다른 이름RAD
Rapid Application Development
유형소프트웨어 개발 방법론
목표짧은 개발 시간
주요 특징반복적인 개발
빠른 프로토타이핑
사용자 참여
개발 단계요구사항 계획
사용자 디자인
구축
전환
장점개발 속도 향상
사용자 만족도 향상
변경 용이성
단점프로젝트 관리 필요
대규모 프로젝트 부적합
숙련된 개발자 필요
적용 분야사용자 인터페이스 중심 응용 프로그램

2. 역사

고속 응용 프로그램 개발(RAD)은 1970년대와 1980년대에 주로 사용되었던 SSADM이나 폭포수 모델과 같은 전통적인 소프트웨어 개발 방식에 대한 대안으로 등장했다. 기존 방식들은 건축이나 토목 공학처럼 물리적인 구조물을 만드는 모델을 기반으로 했기 때문에, 소프트웨어 고유의 유연하고 변경 가능한 특성을 제대로 반영하지 못하는 문제가 있었다.[13][1] 소프트웨어 개발 과정에서 얻는 새로운 지식이나 요구사항 변경을 반영하기 어려운 경직된 구조를 가지고 있었던 것이다. 반면, RAD는 소프트웨어 개발이 지속적인 학습과 지식 축적 과정임을 인식하고, 변화하는 요구사항에 유연하게 대응하며 개발 과정에서 얻은 지식을 최종 결과물에 반영할 수 있는 접근 방식을 추구했다.

RAD의 초기 형태 중 하나는 배리 보헴이 개발한 나선형 모델이다. 보헴을 비롯한 초기 RAD 접근 방식들은 엄격하게 정의된 설계 명세서보다는 프로토타입(시제품) 개발을 강조했다. 프로토타입은 다음과 같은 여러 장점을 제공했다.[2]


  • 위험 감소: 개발 초기 단계에서 시스템의 복잡하거나 불확실한 부분을 미리 시험해 볼 수 있어, 기술적 타당성을 검증하고 구현이 어렵거나 시간이 오래 걸릴 수 있는 방향으로 진행하는 것을 막을 수 있다. 문제를 일찍 발견할수록 해결 비용이 줄어드는 것은 RAD의 핵심적인 장점이다.
  • 사용자 피드백 용이성: 사용자는 추상적인 문서보다는 실제로 동작하는 프로토타입을 사용해 보면서 훨씬 구체적이고 유용한 피드백을 제공할 수 있다. 이는 최종 결과물이 사용자의 실제 요구에 더 잘 부합하도록 돕는다.
  • 점진적 개발 및 조기 가치 제공: 프로토타입은 단순히 시험용 모델에 그치지 않고, 점차 기능을 추가하고 개선하여 최종 제품으로 발전시킬 수 있다. 이를 통해 사용자는 개발 과정 중에도 일부 완성된 기능을 미리 사용하며 비즈니스 가치를 얻을 수 있다.


이러한 아이디어들을 바탕으로 제임스 마틴 (작가)은 1980년대 IBM에서 RAD 접근 방식을 개발했으며, 1991년에 《고속 응용 프로그램 개발》(Rapid Application Developmenteng)이라는 책을 출판하여 이를 공식화했다. 이로 인해 IT 전문가들 사이에서도 RAD라는 용어에 대한 혼란이 발생했다. 폭포수 모델에 대한 일반적인 대안으로서의 RAD와 마틴이 만든 특정 방법으로서의 RAD를 구별하는 것이 중요하다. 마틴 방법은 지식 집약적이고 UI 집약적인 비즈니스 시스템에 맞춰져 있었다.

이러한 아이디어는 RAD 개척자인 제임스 커(James Kerr)와 리처드 헌터(Richard Hunter)에 의해 더욱 발전하고 개선되었으며, 그들은 함께 이 주제에 대한 획기적인 저서인 《Inside RAD》를 저술했다.[3] 이 책은 실제 RAD 프로젝트에서 RAD 방법론을 주도하고 개선하는 RAD 프로젝트 관리자의 여정을 따라갔다. 이러한 실무자들과 그들과 같은 사람들은 RAD가 전통적인 시스템 프로젝트 생명주기 접근 방식의 대안으로 인기를 얻도록 도왔다.

RAD 접근 방식은 또한 업무 프로세스 재설계에 대한 관심이 최고조에 달했던 시기에 발전했다. 업무 프로세스 재설계의 아이디어는 정보 기술의 새로운 기능을 염두에 두고 판매 및 고객 지원과 같은 핵심 비즈니스 프로세스를 근본적으로 재고하는 것이었다. RAD는 종종 더 큰 비즈니스 재설계 프로그램의 필수적인 부분이었다. RAD의 고속 프로토타입 접근 방식은 사용자와 분석가가 기술이 핵심 비즈니스 프로세스를 혁신적으로 재창조할 수 있는 혁신적인 방법에 대해 "틀에서 벗어나 생각"하는 데 도움이 되는 핵심 도구였다.[4][5]

제임스 마틴이 RAD에 대해 편안함을 느낀 데에는 듀퐁의 정보 엔지니어링 부서와 그 책임자인 스콧 슐츠(Scott Shultzeng), 그리고 호주와 홍콩에서 수많은 성공적인 RAD 프로젝트를 개척한 맞춤형 RAD 개발 회사를 이끌었던 존 언더우드(John Underwoodeng)와의 관계가 크게 작용했다.

ANZ 은행, Lend Lease, BHP, 코카콜라 Amatil, 알칸, 홍콩 조키 클럽 등을 포함한 성공적인 프로젝트가 있었다.

이러한 성공으로 인해 스콧 슐츠와 제임스 마틴은 모두 호주에서 존 언더우드와 함께 상당한 미션 크리티컬 RAD 프로젝트를 구현하는 데 있어 호주가 불균형적으로 성공한 이유에 대한 방법과 세부 사항을 이해하는 데 시간을 보냈다.

3. 제임스 마틴의 RAD 접근 방식

배리 보헴 등의 아이디어를 바탕으로 제임스 마틴은 1980년대 IBM에서 고속 응용 프로그램 개발(RAD) 접근 방식을 개발했으며, 1991년에 《고속 응용 프로그램 개발》(Rapid Application Development)이라는 책을 출판하여 이를 공식화했다. 이로 인해 RAD라는 용어에 대한 혼란이 생기기도 했는데, 폭포수 모델에 대한 일반적인 대안으로서의 RAD와 마틴이 만든 특정 방법으로서의 RAD를 구별하는 것이 중요하다. 마틴의 방법은 지식 집약적이고 사용자 인터페이스(UI)가 중요한 비즈니스 시스템에 맞춰져 있었다.

이러한 아이디어는 RAD 개척자인 제임스 커(James Kerr)와 리처드 헌터(Richard Hunter)에 의해 더욱 발전하고 개선되었으며, 그들은 함께 이 주제에 대한 책 《Inside RAD》를 저술했다.[3] 이 책은 실제 RAD 프로젝트에서 RAD 방법론을 주도하고 개선하는 프로젝트 관리자의 경험을 다루었다. 이러한 실무자들의 노력 덕분에 RAD는 전통적인 시스템 프로젝트 생명주기 접근 방식의 대안으로 인기를 얻게 되었다.

RAD 접근 방식은 업무 프로세스 재설계(BPR)에 대한 관심이 높았던 시기에 발전했다. BPR은 정보 기술의 새로운 가능성을 활용하여 핵심 비즈니스 프로세스를 근본적으로 재고하는 것이었다. RAD는 종종 BPR 프로그램의 중요한 부분이었으며, 특히 RAD의 고속 프로토타입 방식은 사용자와 분석가가 기술을 통해 비즈니스 프로세스를 혁신적으로 재창조하는 방법에 대해 창의적으로 생각하도록 돕는 핵심 도구였다.[4][5]

제임스 마틴이 RAD를 개발하는 데 듀퐁의 정보 엔지니어링 부서 책임자인 스콧 슐츠(Scott Shultz)와 호주 및 홍콩에서 다수의 성공적인 RAD 프로젝트를 이끈 존 언더우드(John Underwood)와의 관계가 큰 영향을 미쳤다. ANZ 은행, Lend Lease, BHP, 코카콜라 아마틸, 알칸, 홍콩 조키 클럽 등에서 성공적인 프로젝트를 수행했다. 이러한 성공을 바탕으로 슐츠와 마틴은 존 언더우드가 호주에서 미션 크리티컬 RAD 프로젝트를 성공적으로 구현한 배경과 방법에 대해 연구했다.

제임스 마틴의 RAD 접근 방식 단계


제임스 마틴의 고속 응용 프로그램 개발(RAD) 접근 방식은 전체 프로세스를 다음과 같은 4개의 뚜렷한 단계로 나눈다.[6]

# '''요구 사항 계획 단계''': 사용자, 관리자, IT 직원이 모여 비즈니스 요구 사항, 프로젝트 범위 등을 논의하고 합의하는 단계.

# '''사용자 설계 단계''': 사용자와 시스템 분석가가 협력하여 시스템 모델과 프로토타입을 개발하고 검토하는 단계.

# '''구축 단계''': 실제 프로그래밍, 코딩, 통합, 테스트 등을 통해 시스템을 개발하는 단계. 사용자의 지속적인 참여가 특징이다.

# '''전환 단계''': 개발된 시스템을 실제 운영 환경으로 전환하고 사용자 교육 등을 수행하는 단계.

이러한 단계별 접근 방식을 통해 기존 개발 방법론에 비해 전체 프로세스를 압축하여 새로운 시스템을 훨씬 빠르게 구축하고 제공할 수 있다.[6] 각 단계에 대한 자세한 내용은 하위 섹션에서 다룬다.

3. 1. 요구 사항 계획 단계

요구 사항 계획 단계는 시스템 개발 생명 주기(SDLC)의 시스템 계획 단계와 시스템 분석 단계를 합친 것과 같다. 이 단계에서는 사용자, 관리자, IT 담당자가 모여 비즈니스 요구 사항, 프로젝트의 범위, 여러 제약 조건, 그리고 시스템에 필요한 요구 사항들을 함께 논의하고 합의한다. 팀 전체가 핵심 문제에 대해 동의하고 다음 단계로 진행해도 좋다는 관리자의 승인을 받으면 이 단계는 마무리된다.[6]

3. 2. 사용자 설계 단계

이 단계에서 사용자는 시스템 분석가와 상호 작용하고 모든 시스템 프로세스, 입력 및 출력을 나타내는 모델 및 프로토타입을 개발한다. RAD 그룹 또는 하위 그룹은 일반적으로 공동 애플리케이션 설계(JAD) 기술과 CASE 도구를 조합하여 사용자 요구 사항을 작동 모델로 변환한다. "사용자 설계"는 사용자가 요구 사항을 충족하는 시스템의 작동 모델을 이해, 수정 및 최종적으로 승인할 수 있도록 하는 지속적인 대화형 프로세스이다.[6]

3. 3. 구축 단계

시스템 개발 생명 주기(SDLC)와 유사하게 프로그램 및 응용 프로그램 개발 작업에 중점을 두는 단계이다. 하지만 고속 응용 프로그램 개발(RAD)에서는 사용자가 계속 참여하여 실제 화면이나 보고서가 개발되는 과정에서 변경 또는 개선 사항을 제안할 수 있다는 특징이다. 주요 작업으로는 프로그래밍 및 응용 프로그램 개발, 코딩, 단위 통합, 시스템 테스트 등이 있다.[6]

3. 4. 전환 단계

전환 단계는 데이터 변환, 테스트, 새 시스템으로의 전환, 사용자 교육 등을 포함하며, 이는 시스템 개발 생명 주기(SDLC)의 구현 단계 마지막 작업들과 유사하다. 기존 개발 방식과 비교했을 때 전체 프로세스가 압축되어 진행된다. 그 결과, 새로운 시스템은 훨씬 더 빠르게 구축되고 사용자에게 제공되어 실제 운영에 들어갈 수 있다.[6]

4. 특징

통합 개발 환경(IDE)과 같은 고기능 개발 환경을 통해 프로그래밍을 반자동화하고, 시각적인 사용자 인터페이스(UI) 설계 및 모듈 개발 기능을 제공하는 것이 특징이다.

예를 들어, GUI를 가진 소프트웨어를 개발할 때, 일반적인 개발 도구로는 윈도우 하나를 표시하는 데에도 상당한 양의 소스 코드 작성이 필요하다. 하지만 Visual Basic이나 Interface Builder와 같은 RAD 도구를 사용하면, 프로그래머가 직접 소스 코드를 작성하지 않고도 GUI 부품을 화면에 시각적으로 배치하는 것만으로 윈도우를 만들 수 있다.

또한, 윈도우에 버튼이나 텍스트 상자 같은 GUI 부품을 배치하고 사용자의 조작에 따른 처리를 연결하는 작업(예: 핸들 획득, 속성 설정, 윈도우 메시지 처리) 역시 RAD 도구가 상당 부분 자동으로 처리해 준다. 즉, 많은 소프트웨어에 공통적으로 필요한 코드 작성을 자동화하여 프로그래머는 해당 소프트웨어 고유의 기능 구현에 더 집중할 수 있게 된다. 이는 개발 생산성을 크게 향상시키는 요인이다.

다만, RAD 도구 사용 시 단점으로 자주 언급되는 것은 개발된 소프트웨어의 동작 속도 저하와 실행 파일 크기 증가 경향이다. 하지만 이는 사용하는 도구나 개발 방식에 따라 달라질 수 있으며 절대적인 것은 아니다. 또한, GUI 설계 비중이 낮은 소프트웨어 개발에서는 RAD의 장점을 충분히 활용하기 어려울 수 있다.

5. 장점


  • 품질 향상: 사용자가 개발 과정에 참여하여 지속적으로 개발되는 프로토타입과 상호작용할 수 있다. 이를 통해 폭포수 모델과 같은 전통적인 방식에 비해 실제 사용자의 요구와 비즈니스 목표에 더 잘 맞는 결과물을 만들 가능성이 크다.[2] 소프트웨어의 사용성이 향상되며, 개발자는 기술적인 문제보다는 최종 사용자의 실질적인 비즈니스 문제 해결에 집중할 수 있다.[2][8]
  • 위험 관리: 개발 초기 단계부터 프로토타입을 만들어 시스템의 복잡하거나 구현하기 어려운 부분을 미리 시험해 볼 수 있다.[1] 이를 통해 기술적 문제나 설계 오류와 같은 주요 위험 요소를 조기에 발견하고 대응할 수 있다. 위험을 일찍 발견하고 해결할수록 비용과 시간을 절약하고 프로젝트 실패 가능성을 줄일 수 있다. 이는 배리 보헴이 나선형 모델에서 강조했던 위험 기반 접근 방식과 유사하다.[2][8]
  • 납기 및 예산 준수: 프로젝트를 작은 단위로 나누어 점진적으로 개발하고 테스트하므로, 폭포수 모델과 같은 방식에서 발생하기 쉬운 대규모 프로젝트 실패 위험을 줄일 수 있다. 개발 과정에서 문제가 발생하더라도 초기에 발견하고 수정할 수 있어, 전체 프로젝트가 정해진 일정이나 예산을 초과할 가능성을 줄인다.[2][8]

6. 단점

고속 응용 프로그램 개발(RAD) 방식은 여러 장점에도 불구하고 다음과 같은 단점을 가지고 있다.


  • 새로운 접근 방식의 위험: 대부분의 IT 환경에서 RAD는 새로운 접근 방식이므로, 숙련된 전문가라 할지라도 기존의 작업 방식을 바꿔야 하는 어려움이 있다. 일반적으로 사람들은 변화에 저항하는 경향이 있으며, 새로운 도구나 방법론을 도입하는 프로젝트는 팀의 학습 곡선으로 인해 초기 실패 가능성이 높아질 수 있다.
  • 비기능 요구사항 강조 부족: RAD는 기능 구현에 집중하는 경향이 있어, 보안, 이식성, 성능 등 최종 사용자의 눈에 직접적으로 보이지 않는 비기능적 요구사항을 간과할 수 있다.
  • 부족한 자원의 시간 요구: RAD는 개발 초기부터 완료까지 사용자와 개발자 간의 긴밀하고 지속적인 상호작용을 필요로 한다. 이는 폭포수 모델처럼 요구사항 정의 단계 이후 사용자의 참여가 줄어드는 방식과 대조적이다. 따라서 프로젝트 성공을 위해서는 현업 전문가인 사용자가 프로젝트에 충분한 시간을 투입해야 하는데, 핵심 인력일수록 본업으로 바빠 시간 할애가 어려울 수 있다. 이러한 사용자 측의 적극적인 참여 없이는 RAD 프로젝트의 성공을 기대하기 어렵다.
  • 통제력 부족: RAD의 장점인 유연성은 필연적으로 통제력 약화라는 단점을 동반한다. 변화에 빠르게 적응할 수 있는 유연성이 중요한 프로젝트도 있지만, 생명 유지 소프트웨어 개발과 같이 사소한 오류도 용납되지 않아 엄격한 통제가 필수적인 프로젝트에는 RAD 방식이 적합하지 않다. 유연성과 통제는 상충 관계에 있기 때문이다.
  • 설계 문제: 프로토타입 제작과 빠른 피드백에 지나치게 집중하다 보면, 전체 시스템의 아키텍처를 깊이 고민하기보다 당장의 요구사항을 만족시키는 데 급급한 '해킹과 테스트' 방식에 빠질 위험이 있다. 이는 장기적으로 유지보수가 어렵고 비효율적인 시스템 설계를 초래할 수 있으며, 특히 사용자 인터페이스(UI) 개선에 초점을 맞춘 방법론에서 두드러질 수 있다.[9]
  • 확장성 부족: RAD는 일반적으로 중소규모 프로젝트와 팀에 더 적합하다. 대규모 시스템 개발에 RAD를 적용할 경우, 앞서 언급된 설계 문제나 통제력 부족 문제가 더욱 심화되어 프로젝트 관리에 어려움을 겪을 수 있다.[10][11][12]

7. RAD 도구

대표적으로 다음과 같은 도구를 사용한다.

참조

[1] 서적 No Silver Bullet Essence and Accidents of Software Engineering http://www.sci.brook[...] Elsevier Science Publishers B.V (North-Holland) 2014-07-02
[2] 간행물 A Spiral Model of Software Development http://www.dimap.ufr[...] 2014-07-01
[3] 서적 Inside RAD: How to Build a Fully Functional System in 90 Days or Less McGraw-Hill 1993
[4] 서적 Post-Capitalist Society https://archive.org/[...] Harper Collins e-books 2009-11-03
[5] 서적 Rapid Application Development https://archive.org/[...] Macmillan 1991
[6] 서적 Rapid Application Development https://archive.org/[...] Macmillan 1991
[7] 웹사이트 The Disintegration of AD: Putting it Back Together Again http://www.gartner.c[...] gartner.com.br 2010-04-13
[8] 서적 Extreme Programming Explained https://archive.org/[...] Addison Wesley 2000
[9] conference Practical Implications of Rapid Development Methodologies 2007-11-16
[10] 서적 First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007) 2007-09
[11] 서적 25th International Conference on Software Engineering, 2003. Proceedings
[12] 서적 Extreme Programming Refactored: The Case Against XP https://archive.org/[...]
[13] 서적 No Silver Bullet Essence and Accidents of Software Engineering http://www.sci.brook[...] Elsevier Science Publishers B.V (North-Holland) 1986


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com